Synchronizing distributed work through document logs

ABSTRACT

A method and apparatus is disclosed herein for synchronizing distributed work. In one embodiment, the method comprises receiving first and second metadata entries, adding the first and second metadata entries to a set corresponding to a digital object, and providing access to first and second unique identifiers used for referencing the first and second metadata entries respectively, where the first and second unique identifiers are based on contents of the first and second metadata entries respectively.

CROSS-REFERENCE TO RELATED APPLICATION

This application may be related to U.S. application Ser. No. 11/322,435,filed on Dec. 29, 2005, entitled “Coordination and Tracking ofWorkflow,” assigned to the corporate assignee of the present inventionand incorporated herein by reference.

This is a continuation of U.S. application Ser. No. 10/887,998, filed onJul. 9, 2004, entitled “Synchronizing Distributed Work Through DocumentLogs,” assigned to the corporate assignee of the present invention andincorporated herein by reference.

FIELD OF THE INVENTION

The present invention relates to the field of digital objectdistribution; more particularly, the present invention relates tosynchronizing information corresponding to a digital object.

BACKGROUND OF THE INVENTION

Millions of documents are sent back and forth every day. Substantialeffort and time is spent in the overhead of addressing these documents.In the workplace, this substantial time and effort results in increasedcost and expense.

One typical problem with documents involves the synchronization ofdistributed work. Synchronization of distributed work involves thearrangement of work. When the work involves a document, suchsynchronization may involve coordinating the information correspondingto the document. For example, when a number of parties are makingcomments about a document, the comments may be arranged and/or orderedto provide a better understanding or a more complete state of thedocument's review.

Many document management systems have been proposed and implemented inthe past. These document management systems include systems that storedocuments and handle the coordination of requests with responses.However, these systems do not cur across organizational boundaries anddo not perform the synchronization that is necessary.

A Web log is an online document management tool used to recordinformation. Web logs use a client-server framework to permit theaddition or subtraction of content from one or more client locations toa server that hosts the web log. Because one server hosts each web log,web logs are typically anchored to a particular HTTP location.

SUMMARY OF THE INVENTION

A method and apparatus is disclosed herein for synchronizing distributedwork. In one embodiment, the method comprises receiving first and secondmetadata entries, adding the first and second metadata entries to a setcorresponding to a digital object, and providing access to first andsecond unique identifiers used for referencing the first and secondmetadata entries respectively, where the first and second uniqueidentifiers are based on contents of the first and second metadataentries respectively.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will be understood more fully from the detaileddescription given below and from the accompanying drawings of variousembodiments of the invention, which, however, should not be taken tolimit the invention to the specific embodiments, but are for explanationand understanding only.

FIG. 1 illustrates an exemplary user interface;

FIG. 2 illustrates the view of a log associated with the radiology imagethat was referenced by the highlighted comment in FIG. 1;

FIG. 3 illustrates an exemplary sketch of a XML file that represents thelog associated with a document;

FIG. 4 is a diagram depicting the configuration of clients that submitentries to the rendezvous point for a particular document;

FIG. 5 is a flow diagram of one embodiment of a synchronization process;

FIG. 6 is a flow diagram of one embodiment of a data process;

FIG. 7 is a flow diagram of one embodiment of an access process;

FIG. 8 is a flow diagram of one embodiment of an encryption process;

FIG. 9 is a flow diagram of one embodiment of an entanglement process;

FIG. 10 is a flow diagram of one embodiment of a hash-based searchingprocess;

FIG. 11 is a flow diagram of one embodiment of a transaction process;and

FIG. 12 is a block diagram of an exemplary computer system.

DETAILED DESCRIPTION OF THE PRESENT INVENTION

A method and apparatus for synchronizing data centered around digitalobjects (e.g., documents) that scales up to arbitrary sized groups orsets. In one embodiment, the synchronization is performed using aconceptual framework referred to herein as “document logs.” Documentlogs are similar to Web logs. Document logs differ from Web logs in thatthey are anchored to a particular document, rather than the HTTPlocation that anchors web logs.

In one embodiment, a document log has log entries. Individual logentries consist of metadata. The metadata may comprise short textmessages and/or optional links entered by one or more people orautomated systems. The document log may be distributed. In oneembodiment, the document log is distributed as XML.

Unlike the client/server framework of weblogs, document log distributionand processing is a process distributed among nodes (e.g., units,devices, etc.) connected in a network. The process can be arbitrarilyscaled. In one networked environment, each node minimally providescaching and synchronization for log entries, and the ability to exchangeentries with other nodes. Additionally, user interface nodes (e.g.,clients) provide views of entries and the anchoring document along witha mechanism for adding new entries and/or following links.

In one embodiment, for any given document log or set of logs, a singlenode is designated as responsible for synchronizing log entries. Therole of this “synchronizing” node is to synchronize distributed worksimilar to the role that domain name servers (DNS) provide forconverting domain names into locations (IP addresses). The synchronizingnode may be a server. In particular, the synchronizing node provides acanonical ordering of entries for each document log. In otherembodiments, such synchronization may be performed locally by serving asingle workgroup or globally via a Web service corresponding to the rootdomain name server). Two nodes that agree to use the same synchronizingnode can then rely on having the same ordering for the entries.

In addition to describing a system architecture and operation, a methodand apparatus for processing a transaction using a global rendezvouspoint service is described. In essence, an entity wishing to have theirlog entry added to the canonical sequence of entries for a document paysa transaction fee to the service. Once an indication has been generatedindicating that payment as been received, the log entry may be added.

In one embodiment, document logs are used in conjunction with encryptionto provide secure exchange of documents without trusted third parties.

Taken together, document logs and associated processing provide basicbuilding blocks useful for content management and distribution includingversion tracking, flexible filesharing, synchronization, and the like.Unlike existing document management systems, source code repositories,or other existing mechanisms to achieve these goals, in one embodiment,document logs require no software installation or administrativemaintenance. Furthermore, document logs provide the flexibility forusers to efficiently work together.

In the following description, numerous details are set forth to providea more thorough explanation of the present invention. It will beapparent, however, to one skilled in the art, that the present inventionmay be practiced without these specific details. In other instances,well-known structures and devices are shown in block diagram form,rather than in detail, in order to avoid obscuring the presentinvention.

Some portions of the detailed descriptions that follow are presented interms of algorithms and symbolic representations of operations on databits within a computer memory. These algorithmic descriptions andrepresentations are the means used by those skilled in the dataprocessing arts to most effectively convey the substance of their workto others skilled in the art. An algorithm is here, and generally,conceived to be a self-consistent sequence of steps leading to a desiredresult. The steps are those requiring physical manipulations of physicalquantities. Usually, though not necessarily, these quantities take theform of electrical or magnetic signals capable of being stored,transferred, combined, compared, and otherwise manipulated. It hasproven convenient at times, principally for reasons of common usage, torefer to these signals as bits, values, elements, symbols, characters,terms, numbers, or the like.

It should be borne in mind, however, that all of these and similar termsare to be associated with the appropriate physical quantities and aremerely convenient labels applied to these quantities. Unlessspecifically stated otherwise as apparent from the following discussion,it is appreciated that throughout the description, discussions utilizingterms such as “processing” or “computing” or “calculating” or“determining” or “displaying” or the like, refer to the action andprocesses of a computer system, or similar electronic computing device,that manipulates and transforms data represented as physical(electronic) quantities within the computer system's registers andmemories into other data similarly represented as physical quantitieswithin the computer system memories or registers or other suchinformation storage, transmission or display devices.

The present invention also relates to apparatus for performing theoperations herein. This apparatus may be specially constructed for therequired purposes, or it may comprise a general purpose computerselectively activated or reconfigured by a computer program stored inthe computer. Such a computer program may be stored in a computerreadable storage medium, such as, but is not limited to, any type ofdisk including floppy disks, optical disks, CD-ROMs, andmagnetic-optical disks, read-only memories (ROMs), random accessmemories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, or any typeof media suitable for storing electronic instructions, and each coupledto a computer system bus.

The algorithms and displays presented herein are not inherently relatedto any particular computer or other apparatus. Various general purposesystems may be used with programs in accordance with the teachingsherein, or it may prove convenient to construct more specializedapparatus to perform the required method steps. The required structurefor a variety of these systems will appear from the description below.In addition, the present invention is not described with reference toany particular programming language. It will be appreciated that avariety of programming languages may be used to implement the teachingsof the invention as described herein.

A machine-readable medium includes any mechanism for storing ortransmitting information in a form readable by a machine (e.g., acomputer). For example, a machine-readable medium includes read onlymemory (“ROM”); random access memory (“RAM”); magnetic disk storagemedia; optical storage media; flash memory devices; electrical, optical,acoustical or other form of propagated signals (e.g., carrier waves,infrared signals, digital signals, etc.); etc.

Document Logs in General

A log (e.g., document log) consists of a digital object along with oneor more sets of metadata. The digital objects can be represented as asequence of bytes. The digital object may be a document and the metadatamay correspond to a set of comments associated with the document. Thus,for each document, there exists a set of comments associated with thatdocument. Comments, which generally consist of text strings, may bedocuments themselves and could consist of arbitrary byte strings.Comments may be simple text entries that might refer to other documentsand can be created by anyone or anything. In the context of a drafttechnical paper, a set of comments might represent feedback fromdifferent reviewers. In the context of a photograph (e.g., jpeg file),the set of comments might include stories about the event depicted inthe photograph such as a birthday party. In the context of a patientchart, the set of comments might include references to individualappointments or visits for the patient.

Techniques are described herein for exchanging and merging the lists ofcomments associated with a document together (without conflicts).

In one embodiment, document logs are represented using a simple XMLformat that specifies the “anchoring” document and list of entries. Forexample, a format such as the simple syndication (RSS) format couldeasily be adapted to serve the same purpose.

In one embodiment, an exchange mechanism is used to enable two nodes toexchange a list of entries. In one embodiment, the nodes use the HTTPGET methods to retrieve the XML file corresponding to a document log andthe HTTP POST method to send an XML with (new) entries to a node. Forpurpose herein, GET will refer to the action of retrieving contentassociated with a locator, whether used as part of HTTP or not.Alternatively, other exchange mechanisms, including simple file copyoperations, may be used.

A node may include a user interface to enable an individual to view andadd to the document log entries. Many user interfaces are possible forviewing and adding to document logs. An exemplary user interface isshown in FIG. 1. Referring to FIG. 1, a representation of the image 101on the right hand side and document log entries 102 on the left-handside. On the bottom of the left-hand side is a text box 103 that allowsthe user to type in a new entry.

FIG. 1 shows a prototype user interface for viewing of a document log.In this example, the document is an image (e.g., corresponding to apatient) and the entries correspond to information about that patient.These entries include links to other documents, such as appointments orprocedure results, and their associated logs. Thus, the user interfaceof FIG. 1 facilitates a hypothetical use for tracking patientinformation. On the right side of FIG. 1 is a document, in this case apicture of the patient. Log entries 102 are entries associated with thepatient. Some of these entries are manually typed in by office staff,physicians, or the patient themselves, and other entries are createdautomatically by related systems, such as a scheduling system orradiologic imaging machines. For each entry in such a document log, alink to another document may be included in the entry. A small thumbnail104 of the related document is shown to the right of that entry.

In one embodiment, the “active” comment underneath the cursor isenlarged with a fisheye effect to enable rapid browsing of many commentswithin a single list. In one exemplary user interface, entry 105underneath the mouse cursor is enlarged so as to be easily visible. Inthe example shown here, the highlighted entry may have been createdautomatically by a machine in a manner well known in the art. Theidentifier for the document log shown might have been entered into themachine by use of a bar code or other mechanism on a printed version ofthis document log. An item that was automatically entered into theoriginal document log includes a link to the document log containing theimaging results created automatically by the imaging machine. Clickingon any of entries 102 takes the user to the document log associated withthat entry. Clicking on a comment that has been associated with a linkthat points to a related document takes the user to the view of thedocument and log associated with the referenced document. FIG. 2 showsthe view of a log associated with the radiology image that wasreferenced by the highlighted comment in FIG. 1. Referring to FIG. 2, adocument that was produced automatically by an x-ray machine and thecomments that have been associated with that document are shown.

In some cases, that log will have an entry pointing back to the originallog, but in many cases it will not. Navigation tools at the top of thisprototype viewer provide forward and backward functions similar to astandard web browser.

In addition to images, document types may include wordprocessing files,flash paper, Excel files, text documents, or any other type of data. Inthe current system, any single file (or individually addressable unit)can be used as a “document.”

Documents as Locations

Conceptually, a document log may represent a virtual space or (file)hierarchy. The origin of the space—a “root” node—is defined by thedocument itself. Directory names could be used specify locations of thevirtual space. However, in one embodiment, instead of using directorynames to specify location, the hash values of the documents themselvesare used to specify location of documents and comments on the virtualspace or file hierarchy. For example, /A/C represents a comment (c withC=SHA1(c)) on a document (a with A=SHA1(A)), where SHA1 is a hashfunction that maps an arbitrary sequence of bytes into a fixed sizesequence. That is, the letter A is used to indicate the hash of objecta, A=SHA1(a) where A represents any sequence of bytes. For example thestring “This is a character string.” maps into‘97d981dad06b03622cbf8e1a5642724cbcae64f8’ (using hexadecimal notation).

The storage associated with this representation could be a standarddirectory structure, for example, A as the name of a directory and C asthe name of a file containing the comment on a. Other storagemechanisms, such as a database using the hash values as primary keys,would work equally well and any node may use one or more such storagemechanisms. A confusing case in which the value of a is itself a stringwhich can be interpreted as a path or a uniform resource locator (URL).If a=‘http://foo.com/path/to/file.ext’ then it may be ambiguous whetherc is a comment about the location, is a comment about a web page whosecontents might change, or a comment about the contents of that web pageat some particular point in time. In the latter case, it is safer to usethe hash of the contents (if available) as the anchoring document ratherthan the hash of the reference string as the anchor.

Note that if a is a string and a valid URL, then individual nodes maychoose to combine comments on the string as well as comments on the“known” contents that have been obtained from that URL. Also note thatby convention, the document log of a might include an entry for each ofthe contents that has been available from a along with the pointers tothe document log associated with this particular contents.

For purposes of the description herein, in one embodiment, a document isan immutable object identical to a particular sequence of bytes, and thehash value of a document is used as a reference to that document. Sincedifferent versions of a document have different hash values, thedifferent versions are considered to be different documents. (Byconvention if D2 is a new version of document D1, the log of document D1will have an entry pointing to D2 and the log of D2 will have an entrypointing back to D1.)

More specifically with respect to the use of hash functions anddirectory structures, for example, a JPEG file, a Word document, apostscript document, a text string, etc. a_(u) indicates a location(e.g., a URL) of object a, such as http://www.server.com/path/a.jpg orfile:///path/to/a.jpga=GET(a _(u))(a is the result of de-referencing a_(u))

Let A_(u) denote the set of locations a_(u) for which SHA1(GET(a_(u)))=A

Note that A_(u) indicates a location that returned a stringrepresentation of A.

A new “virtual” SHA1 protocol may be defined as follows:

-   SHA1://host.name/A/B/C that represents a relationship between A, B,    C and their corresponding values, a, b, and c. The value b is a    comment (or document log entry) on a, while c is a comment on b.

As with any URL, if GET(SHA1 ://host.name/A/B/C) succeeds, it returnssome content as a string of bytes. Unlike other protocols, this contentis c and therefore is not just identical for any host, but is also beimmutable. In other words, it is an error if SHA1(GET(SHA1:// . . . /C))does not equal c. Thus, if a node has a copy of c, then it does not needto perform any communications to return GET(SHA1:// . . . /C) (assumethat clients compute SHA1(c) and store the results and any lookup tableusing C as the key).

Note that just as the same image file may be located in several places,the same comments may be related to several documents. If c is a commenton b, then both SHA1:///A/B/C and SHA1:///B/C are valid URLs. Thecomment c might also be a comment on document X, in which caseSHA:1:///X/C would also be valid. Valid in this sense means that someoneor some process actually added c as a comment on documents x and b

Document Log Listings

By convention a trailing slash is used to indicate a listing of commentsassociated with a document. In one embodiment, GET(SHA1://host.com/A/)returns from host.com a listing of comments on document a (in thestandard XML format). Likewise, SHA1://foo.com/A/ refers to a listingfrom host foo.com. /A/ is a reference to the locally known comments ona. SHA1://host.com/A/C/ refers to a listing of comments on comment afrom host.com, etc.

An exemplary algorithm for performing lookup of H/A/C is as follows:

a) check local storage for C (storage can be hash table, database, filedirectory, etc.)

b) if available, then get and return associated value (e.g., content)(Note if instead the set, C/, is being looked up, then add theassociated set to results and (optionally) continue check local storagefor A, if found, then get associated set of comments)

c) compute hashes of comments

d) if any comment has hash C, return that comment

e) look up domain name H (which may also be a hash of the stringcorresponding to a URL, which is handled below)

f) send GET request to H with A/C

g) return results (and optionally check for valid hash)

h) send the request to one or more preconfigured servers (note that theservers may have been previous locations for getting A or a)

i) if H is a hash of a URL, h, then use that URL in a normal GET requestthat should return a

The h/ or h.xml or similar standard variations on h can be used by theclient as a request to the server for list of comments (e.g., XML file),which can be used to compute C (e.g., if c is one of the entries in thatfile).

Clients may also maintain a list mapping A to u1 and u2, where u1 is aset of locations from which the client has obtained a (or informationbased on a) and u2 are locations containing comments on a (e.g., XMLfiles). In an alternative embodiment, the client may simply look up u2,retrieve the associated set(s) of comments, and attempt to compute C.

Mapping Between SHA1: and HTTP: URLs

In one embodiment, clients define and maintain their own mapping fromparticular contents to locations. For example, suppose r is the contentsof Ricoh Innovations homepage. Then r_(u) is http://www.rii.ricoh.com/and R=‘c2c0bfe479dd6da1d58ec4d0c42c5c7c10a1acfe’ (that is the hash valueof ‘Welcome to RII’ which for this example is the entire contents ofindex.html=r).

In this case, a client might maintain an internal table with thefollowing entries: SHA1 (R) HTTP: (r_(u)) Notes c2c0bfe479ddhttp://www.rii.ricoh.com/ The “original” URL. (Note that the has valuehas been truncated here to conserve space) /cache/c2c0bfe479dd/file.htmla local copy of the document contents /c2c0bfe479dd/http://www.rii.ricoh.com/rss.xml A conventional place to find commentsassociated with a particular web site. /cache/c2c0bfe479dd/rss.xml Locallisting of known entries on this document.

Note that the hash values do not need to be of the same length. Inparticular, the more bits of the hash value that are specified, the more“secure” the value is. Therefore, in cases where an encryption key, K,is discussed herein as being based on the content and an identifier, I,based on the content, K and I could be different portions of the outputof the same algorithm or they could be the output of differentalgorithms. That is, although I is the hash of x and K is the hash of I.Equally well, I could be the first 80 bits and K could be bits 81-160 ofthe same hash computation.

Note that there is no requirement for a node or server which stores,processes, presents, or adds to a document log for A to actually haveaccess to the content a. However, by convention for a server, forexample, cache.com, that actually does have a cache or copy of thecontents of documents, it can provide those contents in response torequests for the document, such as http://cache.com/A, and provide thelist log entries in response to http://cache.com/A/. In this case, thepath component of the HTTP: and SHA1: URLs that refer to the samedocument could be identical.

To retrieve an individual comment, the client might requesthttp://cache.com/A/C (Again, note that cache.com may have access to andreturn c even if it does not have access to a.) If c refers to anotherdocument, b by location (e.g., HREF=HTTP://foo.com/b.html sob_(u)=HTTP://foo.com/b.html), then the client might be able to retrieveb from b_(u), calculate B and locate the document log entries associatedwith B, via GET(SHA1:///B/). In one embodiment, by default the clientchecks and integrates log entries from several locations including therendezvous point server, its local cache, foo.com/b.html.xml, and soforth.

Of course, c might also specify that link by a SHA1:URL (e.g.,b_(u)=SHA1:/B) in which case the client uses some mechanism foridentifying the location from which to download the actual contents b ifit did not already have b or an alternative HTTP: version of b_(u).

Synchronization Between Two Nodes

In one embodiment, an individual client keeps a local cache of entriesfor each document. These may be stored in a hash table. The local cachemay be any memory space or storage location. In one embodiment, theentry for each hash consists of 2 parts. The first part is either astring containing the actual content itself and/or one or more pointersto the actual content (if available), and the second part is a list ofhash values that correspond to comments on this document. The client canbe configured to check one or more places for lists of entries. In oneembodiment, a default location is rendezvous point, or synchronizingserver, which might be checked periodically, such as, for example,whenever the user views a document.

When the client obtains additional entries, e.g., the result of a GEToperation, those entries are added to the local cache (consistencychecks may be done to ensure that the content is equal to the hashvalue) and the local list of entries is updated to reflect the newentries. (Information such as the sequence number obtained from asynchronizing server may be used to order this list for presentation.)

Note that nodes in one embodiment of the system of exchange aresymmetric. The only difference between a client and server is that theclient is defined as the machine that initiates communication—using GETto retrieve an entry listing or POST to send a listing. Of course,different nodes (in particular ones that act as servers) might alsodiffer in their configuration, most especially in whether or not willaccept entries from particular nodes (clients).

Nodes might keep track of their communication with other nodes (eitherother clients or servers) and send only “new” entries to the other node(either via a POST or in response to a GET).

Also note that additional exchange protocols may be used, such as, forexample, simply copying and appending the contents of two XML files thatrefer to the same document log into a single file.

Any number of XML representations could be used for the document logentries. FIG. 3 shows an exemplary sketch of a XML file that representsthe log associated with document A. In addition to the content (“Firstcomment on doc A”), each entry has a number of attributes that may beassigned by the originator of the entry or another node. In FIG. 3, theSEQ attribute is assigned by the rendezvous point server. This XMLdocument itself would be returned in response to a query for thedocument log associated with A, by convention this query takes the form//rp.com/A/ where “rp.com” is the host name for the rendezvous point.(Other servers/hosts would return their own versions of this listing.The sequence numbers provided by the rendezvous point are designated as“canonical.”) Note that the HREF attribute on an entry specifies a linkto another document similar to the HREF attribute of an anchor

a href= . . .

<a href= . . . >tag in HTML. Likewise, the SRC tag is analogous to theSRC attribute of the HTML IMG tag and specifies the source of athumbnail image representing the referenced document.

Another possibility would be to use the existing really simplesyndication (RSS) schema. A simple extension to RSS that identifies thebase document (“anchor”) for the RSS feed would enable the usesidentified herein. Alternatively, instead of extending RSS, existingfields in RSS may be used.

Merging comments is an issue since comments are stored according totheir hash value. Note that in addition to the (text) value, attributessuch as, for example, author and date are used in the computation of thehash value, C.

FIG. 4 is a diagram depicting the configuration of clients that submitentries to the rendezvous point for a particular document. Referring toFIG. 4, the overall diagram showing submission of entries from clientsto the rendezvous point. Note that some clients may POST entriesdirectly to the rendezvous point, while others may go throughintermediary nodes. Since entries are referenced and stored by theirhash values, any node can exchange entries directly with any other nodewithout worry of a conflict. Individual nodes can also assign their ownordering to the sequence of entries. The ordering provided by therendezvous point is, by convention, treated as the canonical ordering.Note that the original creator of a document might specify a rendezvouspoint or “root” for the log entries associated with that document byspecifying the root or rp attribute of the initial

doc . . .

element. Note however that a document log may be created by anyone, notnecessarily just the creator of the document. (The creator of a documentdoes have the first opportunity to register an initial log entry on thedocument.) Other nodes may or may not choose to use the root attributesspecified in the document element.Document entries may be made whileoff-line and later automatically synchronize those entries with one ormore servers.

The order of entries seen by the rendezvous point may differ from theactual creation order (especially if some clients are off-line atcreation time). Also the intermediate nodes might aggregate entries frommultiple other nodes and submit.

On the server side for the rendezvous point, in one embodiment, sequencenumbers are assigned in the order in which they are received. Separateconfiguration and confirmation of user identity (e.g., postingauthority) can be handled in any one of several ways. These includeusername and password verification, IP address testing, sessionidentifiers, and the like. In some cases for encrypted content, the usermight have to prove (through cryptographic methods) that they actuallyknow the encryption key A (and/or the content a).

Rendezvous Points and Global Synchronization

As described, the arrangement of nodes above functions quite well forexchanging document logs in a decentralized, scalable, peer-to-peerarrangement. Comments can be made off-line or online and resolvedthrough local exchanges.

However, a significant problem may arise when attempting to coordinatework between multiple clients. Many times those clients need to agree onan ordering or sequence of the entries. Because of simultaneous creationand communication lag times, it may not be possible to construct aunique ordering of those entries. Instead, each node may have its ownunique ordering.

In one embodiment, a web service referred to herein as Rendezvous Point(RP.net) (RP.net is not an available domain name and used purely forexample) provides a global ordering for any document log. In response toPOST requests, such as, for example, POST(http://RP.net/A/C), RP.netassigns a sequence number to comment c in the context of document a. Inresponse to a GET request, RP.net responds to GET(http://RP.net/A/) witha listing of known comments and specifies the sequence number for eachcomment.

In the same manner as servers other than the root domain name serverscan provide DNS functions, in one embodiment, servers other than RP.netcan provide sequence numbers. However, only one service can act as thecannonical service for assigning sequence numbers. In one embodiment,the authority is delegated to other services, but the responsibilityremains with the RP.net organization.

Thus, server accepts metadata (e.g., a comment) and identifier which maybe the hash or other valued related to a digital object (e.g., thedocument being commented on) and, in one embodiment, server assigns asequence number to that metadata entry and publishes the updated list ofsequence numbers and associated metadata entries. The server can publisheither the entry content or identifiers calculated based on the contentof the entries. Also, in one embodiment, the server digitally signs thepublished list.

FIG. 5 is a flow diagram of one embodiment of a synchronization process.The process is performed by processing logic that may comprise hardware(circuitry, dedicated logic, etc.), software (such as is run on ageneral purpose computer system or a dedicated machine), or acombination of both.

Referring to FIG. 5, the process begins by processing logic receiving afirst unique identifier that references a set corresponding to a digitalobject (processing block 501). In one embodiment, the first uniqueidentifier is computed based on content of the digital object. In oneembodiment, the first unique identifier is a hash value that is a resultof applying a hash function that maps an arbitrary sequence of bytesassociated with the digital object into a fixed size sequence.Alternatively, the hash value is a result of applying a hash function oncontent of the digital object.

Note that the digital object may be indexed by the first uniqueidentifier.

Processing logic also receives first and second metadata entries(processing block 502). Note that the sources of the first and secondmetadata entries may be different.

After receiving the first and second metadata entries, processing logicadds the first and second metadata entries to the set (processing block503).

Once added, processing logic provides access to second and third uniqueidentifiers used for referencing the first and second metadata entriesrespectively (processing block 504). The second and third uniqueidentifiers are based on contents of the first and second metadataentries respectively. In one embodiment, the second and third uniqueidentifiers are hash values. In one embodiment, the second and thirdunique identifiers are results of computing a hash value based oncontents of the first and second metadata entries, respectively.

In one embodiment, providing access to the second and third uniqueidentifiers comprises sending a canonical ordering of the second andthird unique identifiers. In another embodiment, providing access to thesecond and third unique identifiers comprises sending sequence numbersassociated the second and third unique identifiers, where each of thesequence numbers is associated with only one of the second and thirdunique identifiers. Note, instead of sending identifiers calculatedbased on the content, the content itself could be sent.

In one embodiment, the process further comprises canonically orderingthe first and second metadata entries (processing block 505) andgenerating (and sending) sequence numbers (processing block 506) asdescribed herein.

In one embodiment, the process further comprises accessing the first andsecond metadata entries using the first and second unique identifiers asindices. In one embodiment, the indices are hash values.

In one embodiment, the first metadata entry corresponds to a descriptionof property for sale by a seller and the second metadata entrycorresponds to an indication from a buyer expressing a commitment topurchase the property. In one embodiment, in such a case, the process ofFIG. 5 further comprises receiving a third metadata entry containinginformation that references either or both of the first and secondmetadata entries. The process of FIG. 5 may also include receiving athird metadata entry (from source, or party, such as for example, anescrow agent, other than the ones providing the first and secondmetadata) containing information related to a transaction to purchasethe property, including information such as, for example, shippinginformation (e.g., shipping dates, tracking numbers, and receptiondates) and payment information.

In one embodiment, the process of FIG. 5 further includes accessrestriction processing to restrict the addition of additional metadataentries to the set of entries based on criteria (e.g. the number ofmetadata entries made on the document). In one embodiment, restrictingaccess is performed by denying a request to add a further comment. Inanother embodiment, restricting access is performed by adding the secondmetadata entry to the set, charging a fee, and preventing publication ofa sequence number associated with the second metadata entry when one ormore other sequence numbers associated with one or more entries in theset are published until after receiving an indication that payment hasbeen received. Such access restriction processing may further comprisepublishing sequence numbers corresponding to entries in the set whilepreventing addition of further metadata entries. The access restrictionprocessing is described in greater detail below.

In one embodiment, the process of FIG. 5 further includes someencryption processing. The encryption processing may include computing ahash of the digital object and encrypting one or both of the digitalobject and the second metadata entry using an encryption key that is afunction of the content of the digital object. In one embodiment, theencryption key is a hash of the digital object. In an alternativeembodiment, the encryption key is a function of an encrypted version ofthe digital object. In one embodiment, the encryption is performed usingDES. In one embodiment, the encryption processing also includes creatingthe encrypted version of the digital object by applying the DESalgorithm to the digital object using the hash of the digital object asthe encryption key. The encryption processing is described in greaterdetail below.

FIG. 6 is a flow diagram of one embodiment of a data process. Theprocess is performed by processing logic that may comprise hardware(circuitry, dedicated logic, etc.), software (such as is run on ageneral purpose computer system or a dedicated machine), or acombination of both.

Referring to FIG. 6, the process begins by processing logic sending afirst unique identifier that references a set corresponding to a digitalobject (processing block 601). Processing logic then receives sequencenumber and unique identifier pairs for each metadata entry in the set(processing block 602). In one embodiment, the unique identifier in thepair is a hash value.

In one embodiment, the process further comprises receiving one or moreadditional entries from another party (processing block 603), generatingunique identifiers for the additional entries (processing block 604),and comparing the generated unique identifiers with received uniqueidentifiers to identify an order between the one or more additionalentries and other entries in the set (processing block 605).

In one embodiment, the process may further include identifying atemporal location of the first unique identifier among uniqueidentifiers in the set.

Business Models

Tying the log entries to particular document contents presents thepossibility for new transactional business models. Each identifiercorresponds to a space. The server may charge individual users to acceptand publish their updated entries. For example, assume an initialidentifier and some number, N, of entries are paid for by user A. Afterthe nth entry, in one embodiment, the sequence is locked until paymentis received (the sequence list is still published, but no updates arepossible). If user B attempts to register an entry, the server deniesthe request (or does not publish the assigned sequence number) untiladditional payment is received (either from A, B, or other interestedparties).

In particular, RP.net might charge on a per “document space” basis toaccept new comments and assign them to that space. For example, RP.netmight charge a at rate (say zero) for the first 100 registered comments.After that, additional registrations might cost some small amount. Thisamount could be paid by the document owner (e.g., the person who addedthe first entry) or by the comment submitter (the person or organizationwishing to add the comment) or other interested parties.

In a typical scenario, the original submitter might wish to start adiscussion, for instance about a particular photo of a birthday party.They send a photo around to their friends and pay RP.net for the first100 comments. Eventually they may lose interest and no longer wish tounderwrite that discussion. Some other person, for instance, the parentof the child having the birthday, might wish to continue the discussion,perhaps something as simple as adding in a link to their own photoalbum. The parent could then pay for and register the 101st comment. Ofcourse, the parent might also just want to enable other people, such asthe grandparents, to continue making comments and pay for another block(e.g., 100) of comment registrations.

In one embodiment, RP.net makes available the currently registeredcomments at no fee. (The fees paid for the initial comments provide, inessence, an ongoing obligation to provide the sequence numbers andpossibly the common contents.) This has the desired effect of making theexisting comments visible and generating demand for people who see thosecomments to add (and pay for) their own. Coupled with the encryptiontechniques described herein, this service and business model worksequally well with public documents and comments as well as privatedocuments and private comments. (There can even be public comments onprivate documents and vice versa all without having to trust RP.net withany private information.)

Many additional variations on this model are possible. The most obviousare restricting registration access on a per document and peruser/organization basis. (For example, the initial comment in a documentlog might be information that limits the posting access to a set ofidentified users, or such configuration information can be handledoutside of the document log mechanism itself.)

FIG. 7 is a flow diagram of one embodiment of an access process. Theprocess is performed by processing logic that may comprise hardware(circuitry, dedicated logic, etc.), software (such as is run on ageneral purpose computer system or a dedicated machine), or acombination of both.

Referring to FIG. 7, the process begins by processing logic accessing adynamically modifiable set of metadata entries corresponding to adigital object (processing block 701). The set of metadata entriescomprises first and second metadata entries.

In one embodiment, the process includes processing logic publishingsequence numbers corresponding to entries in the set without including asequence number for the further comment (processing block 702). Notethat this is not a requirement.

After accessing the set of metadata entries, processing logic restrictsaccess to add a further metadata entry to the set of entries based oncriteria (processing block 703). Restricting access may comprise notaccepting the second metadata entry until some criteria is met or maycomprise denying a request to add a further comment.

In one embodiment, the criterion comprises the number of metadataentries made on the document. In another embodiment, the criterioncomprises the time at which the further metadata entry is to be made.

In one embodiment, restricting access includes adding the secondmetadata entry to the set, charging a fee, and preventing publication ofa sequence number associated with the second metadata entry when one ormore other sequence numbers associated with one or more entries in theset are published until after receiving an indication that payment hasbeen received.

In one embodiment, restricting access may include charging for accessand permitting access after receiving an indication that payment hasbeen received from a party.

Flash Clients

Examples given in FIGS. 1 and 2 use Macromedia flash as the platform forthe user interface client. Flash has the advantage of being extremelyportable (available on a very large number of platforms), includesdynamic capabilities (for example zooming in on entries in a largelist), and natively displaying a large number of document types(including not only text and images, but also video, audio, and “flash”paper.)

Flash players also have the advantage of running inside of browsers andmaintaining local caches which are segmented from the local filesystem.The caches enable smooth online and offline operation, including theability to add document entries while off-line and later automaticallysynchronize those entries with one or more servers. Many other clientsare possible, including, for example, standard HTML with or withoutdynamic scripts such as, for example, JavaScript.

Encrypted Documents

One variation of document logs is to use one level of indirection inreferencing the contents of a. Instead of using A=SHA1(a) as the originfor the document log about a, use AA=SHA1(ENC(a, A)), where A=SHA1(a) isused as an encryption key to encode a. ENC is an encryption algorithm,for example, DES. A can also be used as an encryption key to encode“secret and use A as an encryption key for a and secret comments c. Thevirtual protocol is defined herein DES://A/AC which refers to c where ACis the hash of encrypted version of c using key A in the application ofthe DES algorithm. (Similar notation can be used for RSA and otheralgorithms.) Therefore, GET(SHA1:///AA/) returns the encrypted versionof A represented by DES://A/AA. GET(DES://A/AA) returns a—but can onlybe calculated if the client already knows A. Most often, the clientobtains A by first obtaining a and then calculating A.

In the case the client obtains a from another channel (e.g., theycreated the document or received it as an attachment by e-mail) andnever has a need to actually decrypt the encrypted version of A.However, they can and do use A to encrypt and decrypt commentsassociated with a. While a plain text comment on A could still be storedlocally as SHA1:///A/C, the client would not want to exchange thesecomments directly with any other node (the client should not reveal A toother, potentially unauthorized, nodes.) Instead, the client exchangesSHA1:///AA/C. In other words, clients use and exchange comments on thehash of the encrypted version of a (using A as the encryption key).Secret comments can also be used by using AC (the hash at the encryptedversion of c using A as the encryption key) for the comment “locations.”

In this way, two parties that share the same object (e.g., anything fromajpg file that they exchanged as an e-mail attachment, to a secretpassphrase that they communicated face to face) can communicate securelyabout that object through completely untrusted third parties.

FIG. 8 is a flow diagram of one embodiment of an encryption process. Theprocess is performed by processing logic that may comprise hardware(circuitry, dedicated logic, etc.), software (such as is run on ageneral purpose computer system or a dedicated machine), or acombination of both.

Referring to FIG. 8, the process begins by processing logic receiving afirst unique identifier calculated from a digital object (processingblock 801). The set has at least first and second metadata entries.

Using the identifier of the digital object, processing logic encrypts atleast one of the digital object, the first metadata entry, and thesecond metadata entry using an encryption key that is a function of thecontent of the digital object (processing block 803). In one embodiment,the encryption key is a hash of the digital object. In one embodiment,the encryption key is a function of an encrypted version of the digitalobject. In one embodiment, encrypting one or both of the digital objectand the second metadata entry is performed using DES.

In one embodiment, the process also includes processing logic creatingthe encrypted version of the digital object by applying DES using thehash of the digital object as the encryption key (processing block 804).

In another embodiment, the encryption process may include maintaining adynamically modifiable set of one or more entries corresponding to adigital object, wherein maintaining the dynamically modifiable log bycomputing an identifier (e.g., a hash value) based on the content of thedigital object and performing encryption using the identifier as theencryption key. Performing encryption using the identifier as theencryption key may include encrypting the digital object with theidentifier. In an alternative embodiment, performing encryption usingthe identifier as the encryption key comprises encrypting the hash ofthe digital object with the identifier.

In one embodiment, the identifier is a hash value computed by applying ahash function to the content of the digital object and performingencrypting comprises encrypting the digital object using DES with thehash value as an encryption key. Such a process may also includegenerating the hash of the encrypted digital object and using the hashas an index to access the digital object or encrypting content of anentry using the identifier. In one embodiment, the identifier is thehash of the digital object.

Entanglement

The techniques described herein may be used to make the forgery ofentries into a document log arbitrarily difficult. In one embodiment,synchronizing server SA adds a comment x to the log of a, SHA1:/SA/A/E.The log of a is begun with a verification hash VA, which can only beproduced by knowing a secret qa held by SA. For example, the seed mightbe constructed by taking the MD5 hash of the contents of document aconcatenated with secret q. This seed value VA1 is noted in the log ofa, as the first entry. When comment x is added to the log of a, averification hash VA2 is created by appending VA and hash X of thecomment x, and taking the MD5 hash of the resulting string. Similarly,for the next comment y, a verification hash value VA3 can be created byappending VA2 and hash Y of the comment y and taking the hash of theresulting concatenated string (e.g., VA3=MD5(VA2& SHA1(y)). It can beseen that each entry will verify that it has been appended in a specificorder, and that no entries have been omitted. Any examining authoritycan verify that a particular log is valid and in the correct sequenceorder. Additional security can be provided by digitally signing eachverification hash, using a public/private key pair held by server SA.

It is clear that such logs themselves can be rewritten from thebeginning by computing new hashes. However, logs that are verifiable inthis way can be entangled, which is to say that the logs can refer tothe state of one another in entries. Consider a second document log B,associated to document b, whose synchronizing server is SB. As entriesare added to B, they are also validated with the sequential hashingmechanism noted immediately above. When an entry in B refers to documenta, it can include the last entry of log A, including the verificationhash VA2. This entangles the two logs.

Now, should an attacker wish to replace or remove an entry in logSHA1:/SA/A, he must know of the existence of log SHA1:/SB/B and replacethat log as well. Since no reference to log SHA1:/SB/B can be found inlog SHA1:/SA/A, it is arbitrarily difficult to make an undetectablemodification to log A. With only a small number of cross-referencesbetween document logs, it becomes effectively impossible to find andreplace all log entries that may refer to a given log. Furthermore, amalicious server cannot create a malicious log entry in its own logs,disagreeing with a valid verification hash, because such entries wouldnot have the correct digital signature.

FIG. 9 is a flow diagram of one embodiment of an entanglement process.The process is performed by processing logic that may comprise hardware(circuitry, dedicated logic, etc.), software (such as is run on ageneral purpose computer system or a dedicated machine), or acombination of both.

Referring to FIG. 9, the process begins by creating a first verificationhash value (processing block 901). In one embodiment, the firstverification hash value is created by computing the hash value of astring that results from concatenating a secret q with the contents of adocument a. In one embodiment, the document a corresponds to thedocument for the document log.

Once the first verification hash has been created, processing logic addsthe first verification hash to the first document log (processing block902).

Subsequently, processing logic creates a second verification hash valuefor a comment to be added to the first document log (processing block903). In one embodiment, the second verification hash value is createdby computing the hash value of a string that results from concatenatingthe first verification hash value with a hash of the comment to beadded.

After creating the second verification hash value, processing logic addsthe second verification hash value to the first document log (processingblock 904).

Thereafter, processing logic creates an entry in a second document logthat references the first document log by including the secondverification hash value of an entry in the first document log(processing block 905).

At some time later, processing logic verifies entries in the firstdocument log by accessing the entry in the second document log thatcontains the second verification hash value (processing block 906).

Hash-Based Searching

Hash-based searching may be performed using the techniques describedherein. Given SHA1://host.com/A/B a node which does not yet have contentb may wish to search for b. As mentioned in the text, the node maysearch in local tables or by requesting information from other servers(e.g., host.com or generic search servers). The servers in turn may sendout additional request to yet other servers. While most search enginesrely on content (e.g., key words) or identifiers (e.g., filenames), fewprovide the ability to search by hash value. Of those that do, theygenerally offer a simple global search capability. Systems such asFreenet provide federated searches based on hash values, where clientrequests to server S are forwarded to additional servers S′ depending onthe configuration of S. In contrast, we can use the context, A andhost.com as additional factors in limiting and/or directing the search.As one example, consider the case in which the server S requires thatthe client demonstrate knowledge of a before performing a search orreturning the results of the search for B. Note the client might have tosign the request for B using a where the signature consists ofcalculating the hash value of a concatenated with the stringrepresenting the request for B and supplying that hash value to theserver.

FIG. 10 is a flow diagram of one embodiment of a hash-based searchingprocess. The process is performed by processing logic that may comprisehardware (circuitry, dedicated logic, etc.), software (such as is run ona general purpose computer system or a dedicated machine), or acombination of both. Referring to FIG. 10, the process begins byprocessing logic receiving a search request for content in which searchscope is defined by specifying a hash value and a context for the search(processing block 1001). Then processing logic performs the search(processing block 1002).

Use in Transaction Systems

This sequence operation is a fundamental building block for managingdistributed work. As such, there are many potential usage scenarios.Many such scenarios revolve around transactions, such as the auction ofan item. In a simplified case the seller of an object puts a commentinto the log for that object, the buyer places a comment expressing acommitment to buy, one or more third parties place comments about thetransaction, such as shipping dates, tracking numbers, reception dates,and payment information. Some of these third parties might act as escrowagents, e.g. only placing comments once an “official sequence” numberfor prior comments has been assigned by the synchronizing service (e.g.,the payment service may not publish a comment finalizing payment untilit sees a sequenced comment that the delivery has been received). At anypoint during the process, any involved party can see the current list ofcomments (as well as their own “pending” comments which have not yetbeen sequenced). The synchronizing service enables this type oftransaction without each party having to negotiate separately with theother parties beforehand. This greatly reducing the overhead andadministration and integration costs while providing more flexibilityand visibility than current systems.

FIG. 11 is a flow diagram of one embodiment of a transaction process.The process is performed by processing logic that may comprise hardware(circuitry, dedicated logic, etc.), software (such as is run on ageneral purpose computer system or a dedicated machine), or acombination of both.

Referring to FIG. 11, the process begins by processing logic receiving afirst unique identifier that references a set corresponding to a digitalobject (processing block 1101).

Next, processing logic receives first and second metadata entries(processing block 1102). The first metadata entry corresponds to adescription of property for sale by a seller and the second metadataentry is designed to obtain additional information about the firstmetadata entry. In one embodiment, the additional information comprisesa sequence number corresponding to the first metadata entry. In anotherembodiment, the first metadata entry corresponds to a description ofproperty for sale by a seller and the second metadata entry correspondsto an indication from a buyer expressing a commitment to purchase theproperty.

After being received, processing logic adds the first and secondmetadata entries to the set (processing block 1103).

Once added to the set, processing logic provides access to second andthird unique identifiers used for referencing the first and secondmetadata entries respectively (processing block 1104). The second andthird unique identifiers are based on contents of the first and secondmetadata entries respectively.

In one embodiment, the process also includes processing logic receivinga third metadata entry containing information that references either orboth of the first and second metadata entries (processing block 1105).In one embodiment, the third metadata entry is from another party thatis not a source for the first and second metadata entries. Such a partymay be, for example, an escrow agent. The third metadata entry maycontain information related to a transaction to purchase the property,including shipping information (e.g., shipping dates, tracking numbers,and reception dates) and payment information. In one embodiment, thethird party metadata entry is added only after a sequence number for oneor more prior metadata entries has been assigned.

An Exemplary Computer System

FIG. 12 is a block diagram of an exemplary computer system that mayperform one or more of the operations described herein. Referring toFIG. 12, computer system 1200 may comprise an exemplary client 1250 orserver 1200 computer system. Computer system 1200 comprises acommunication mechanism or bus 1211 for communicating information, and aprocessor 1212 coupled with bus 1211 for processing information.Processor 1212 includes a microprocessor, but is not limited to amicroprocessor, such as, for example, Pentium™, etc.

System 1200 further comprises a random access memory (RAM), or otherdynamic storage device 104 (referred to as main memory) coupled to bus1211 for storing information and instructions to be executed byprocessor 1212. Main memory 1204 also may be used for storing temporaryvariables or other intermediate information during execution ofinstructions by processor 1212.

Computer system 1200 also comprises a read only memory (ROM) and/orother static storage device 1206 coupled to bus 1211 for storing staticinformation and instructions for processor 1212, and a data storagedevice 1207, such as a magnetic disk or optical disk and itscorresponding disk drive. Data storage device 1207 is coupled to bus1211 for storing information and instructions.

Computer system 1200 may further be coupled to a display device 1221,such as a cathode ray tube (CRT) or liquid crystal display (LCD),coupled to bus 1211 for displaying information to a computer user. Analphanumeric input device 1222, including alphanumeric and other keys,may also be coupled to bus 1211 for communicating information andcommand selections to processor 1212. An additional user input device iscursor control 1223, such as a mouse, trackball, trackpad, stylus, orcursor direction keys, coupled to bus 1211 for communicating directioninformation and command selections to processor 1212, and forcontrolling cursor movement on display 1221.

Another device that may be coupled to bus 1211 is hard copy device 1224,which may be used for printing instructions, data, or other informationon a medium such as paper, film, or similar types of media. Furthermore,a sound recording and playback device, such as a speaker and/ormicrophone may optionally be coupled to bus 1211 for audio interfacingwith computer system 1200. Another device that may be coupled to bus1211 is a wired/wireless communication capability 1225 to communicationto a phone or handheld palm device.

Note that any or all of the components of system 1200 and associatedhardware may be used in the present invention. However, it can beappreciated that other configurations of the computer system may includesome or all of the devices.

Whereas many alterations and modifications of the present invention willno doubt become apparent to a person of ordinary skill in the art afterhaving read the foregoing description, it is to be understood that anyparticular embodiment shown and described by way of illustration is inno way intended to be considered limiting. Therefore, references todetails of various embodiments are not intended to limit the scope ofthe claims that in themselves recite only those features regarded asessential to the invention.

1. A method comprising: sending a first unique identifier thatreferences a set corresponding to a digital object; and receivingsequence number and unique identifier pairs for each metadata entry inthe set.
 2. The method defined in claim 1 further comprising:identifying a temporal location of the first unique identifier amongunique identifiers in the set.
 3. The method defined in claim 2 furthercomprising: receiving one or more additional entries for another party;generating unique identifiers for the additional entries; and comparingthe generated unique identifiers with received unique identifiers toidentify an order for the one or more additional entries and otherentries in the set.
 4. The method defined in claim 1 wherein the uniqueidentifier in at least one of the pairs is a hash value.
 5. An articleof manufacture having one or more recordable medium storing instructionswhich, when executed by a computer, cause the computer to: send a firstunique identifier that references a set corresponding to a digitalobject; and receive sequence number and unique identifier pairs for eachmetadata entry in the set.
 6. An apparatus comprising: a processing unitto send a first unique identifier that references a set corresponding toa digital object; and an input unit coupled to the processing unit toreceive sequence number and unique identifier pairs for each metadataentry in the set.
 7. An apparatus comprising: means for sending a firstunique identifier that references a set corresponding to a digitalobject; and means for receiving sequence number and unique identifierpairs for each metadata entry in the set.